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NOTE:  For  the  purposes  of  this  report  the  terms  Commander, 

Strategist,  gamer,  user,  game  participant  and  game  player 
are  used  to  refer  to  those  who  are  acting  participants 
in  the  command,  control  and  communication  system  of  a 
scenario  being  played. 


1.0  INTRODUCTION 


This  report  is  submitted  to  the  Rome  Air  Development  Center  (RADC),  Griffis 
Air  Force  Base,  New  York,  to  support  contract  requirements  set  forth  in  Re¬ 
quest  for  Proposal  (RFP)  F30602-79-C-0183.  This  report  addresses  the  Contract 
Data  Requirements  List  (CDRL)  Number  A002  of  the  contract  which  this  effort 
supported;  i.e.,  computer  simulated  war  scenarios. 

For  the  purpose  of  this  report,  reference  to  "ASGX  concept"  or  "ASG1"  is  to 
imply  a  proposed  automated  scenario  generator  and  the  capability  to  interact 
with  it  (play  that  scenario) . 

Computer  simulated  war  scenarios  currently  used  by  the  U.S.  military  for  train¬ 
ing  exercises  have  proven  to  be  effective  in  approaching  a  cost-effective 
means  by  which  flag  grade  and  field  grade  commanders  can  experience  true-to- 
llfe  combat  situations.  The  ability  to  allow  commanders  to  make  certain  de¬ 
cisions  given  a  specific  set  of  circumstances  and  to  analyze  these  decisions 
provides  data  which  can  be  used  to  construct  a  baseline  for  determining  the 
effectiveness  of  command,  control,  and  communications  decision^. 

A  computerized  simulated  war  program  currently  in  use  by  the  U.S.  Air  Force 
and  U.  S,  Army  is  the  TACTICAL  AIR/LAND  OPERATIONS  (TALON)  computer  program 
which  simulates  Blue  force  reconnaissance  (RECCE),  Red  and  Blue  forces  ground 
warfare,  and  Blue  force  Close  Air  Support  (CAS)  and  Mobile  Interdiction  (MI) 
air  strike  operations.  Although  the  TALON  program  is  an  effective  training 
aid,  it  has  definite  limitations  in  the  scope  of  its  true-to-li£e  simulation. 

An  effective  combat  gaming  model  simulates  movements  by  the  military  elements 
of  both  friend  and  foe.  Each  player,  where  player  1b  defined  as  one  who  is  an 
active  participant  in  the  scenario  being  played,  should  have  the  Bame  capabil¬ 
ities  when  engaging  in  a  combat  game,  i.e.,  each  player  should  have  the  option 
of  undertaking  an  offensive  or  defensive  role  according  to  how  he  determines 
his  mission  objectives  can  best  be  fulfilled.  For  example,  the  Blue  player 
should  have  the  same  resources  and  weapons  access  capabilities  as  the  Red 
playet;  moreover,  both  players  should  have  the  Bame  options  of  mobility  and 
tactical  definition  of  weapons  use.  Additionally,  the  use  of  any  weapons  by 
either  player  should  be  subject  to  conditions  including  but  not  limited  to  the 
Rules  of  Engagement  (ROE)  for  each  participant  and  weather,  terrain,  tactical 
situation.  These  limitations  and  the  number  of  limitations  should  be  open 
ended  in  extent  and  scope. 

Game  play  should  be  conducted  in  an  environment  where  all  players  maintain  a 
complete  interactive  operational  mode  with  the  gaming  program  to  allow  all 
players  to  react  to  responses  of  his  adversary.  The  advantages  to  this  method 
are:  (1)  the  ability  to  analyze  a  player* b  response  to  a  given  situation  at 
the  time  that  the  situation  arises;  (2)  to  allow  each  player  to  construct 
mission  objectives  which  would  result  in  the  gain  or  the  loss  of  overall  ob¬ 
jectives  in  the  combat  situations;  (3)  to  give  ull  the  players  a  continuous 
overall  picture  of  the  theater  in  which  a  combat  situation  is  being  modeled. 


1. 


The  combat  gaming  model  described  called,  The  Automatic  Scenario  Generation 
and  Interaction  (ASGI) ,  is  a  concept  employing  a  complete  interaction  en¬ 
vironment  by  all  players  engaged  in  computerized  combat  games.  In  addition, 
the  development  of  the  scenarios  themselves  by  the  operational  staff  would 
be  interactive  in  nature,  thereby  reducing  the  time  required  to  develop  new 
scenarios.  The  use  of  an  ASGI  concept  allows  rapid  construction  of  elements 
needed  to  represent  any  given  situation  and  to  expose  gamers  to  that  situa¬ 
tion  in  a  timely  and  cost  effective  manner. 

2.0  OBJECTIVES 

The  objectives  of  this  report  are:  (1)  to  analyze  and  investigate  the  appli¬ 
cation  of  present  scenario  generation  and  Interaction  te-'hniques  aB  they  are 
being  applied  to  training  exercises;  (2)  to  present  the  re>  .  .r.s  of  interviews 
with  U.S.  Air  Force  and  U.S.  Army  personnel  which  examined  the  human  impacts 
on  training  exercises;  (3)  to  describe  the  capabilities  and  limitations  of 
the  present  techniques  in  scenario  generation  and  interaction;  (4)  to  de¬ 
scribe  the  technical  approaches  proposed  by  Martin  Marietta  for  developing 
the  advanced  ASGI  concept. 

3.0  APPROACH 

In  accomplishing  the  objectives,  it  was  necessary  to  analyze  the  available 
documentation  for  the  various  U.S.  Air  Force  Command,  Control  and  Communica¬ 
tions  (C3)  training  exercises,  to  provide  a  summary  of  results  of  the  analy¬ 
sis,  to  annotate  recommendations  for  correction  of  perceived  deficiencies, 
and  to  provide  a  top  level  discussion  of  a  theoretical  automated  war  scenario 
generator  and  interaction  system  which  could  be  implemented  by  the  U.S.  Air 
Force  to  conduct  C3  training  exercises. 

Models  other  than  the  U.S.  Air  Force  Tactical  Air/Land  (TALON)  program  were 
examined,  such  as  the  Scenario  Oriented  Recurring  Evaluation  System  (SCORES). 
The  structure  of  TALON  is  very  similar  in  design  and  design  philosophy  to 
that  of  SCORES,  which  is  limited  to  a  ground  war  model.  The  capabilities  of 
TALON  with  respect  to  scope  and  interactive  use  by  the  operations  personnel 
and  the  system  users  are  as  extensive  as  any  automated  system  surveyed.  In 
addition,  the  TALON  documentation  UBed  in  this  study  is  unclassified  whereas 
the  SCORES  documentation  available  was  classified.  In  order  to  fully  explore 
the  capabilities,  design  and  structure  of  a  representative  automated  gaming 
system  in  use,  TALON  was  chosen  for  an  in-depth  study  to  illustrate  the  state 
of  the  art  being  used  operationally.  The  study  of  TALON  provides  some  under¬ 
standing  of  the  effectiveness  of  the  model. 

The  approach  taken  in  conducting  this  analysis  was  two  phased.  The  first 
phase  consisted  of  conducting  interviews  with  U.S.  .iir  Force  personnel  who 
are  associated  with  the  planning,  conducting,  and  analysis  of  C3  type  combat 
exercises.  Data  collected  from  these  interviews  provided  a  requirements 
baseline  from  which  the  proposed  automated  scenario  generator  (ASGI)  in  this 
report  was  conceived. 

Phase  two  of  the  approach  consisted  of  the  analysis  and  comparison  of  the 
U.S.  Air  Force  TALON  computer  model  and  the  proposed  ASGI  concept  described 


in  this  report.  The  format  of  this  analysis  is  broken  down  by  subject  or 
function.  The  TALON  model,  and  its  capabilities  and  limitations  are  discuL3ed. 
Following  the  TALON  discussion  is  a  review  of  the  porposed  ASGI  concept. 

Where  applicable,  comparisons  will  be  made  between  the  TALON  and  the  ASGI 
concepts  in  the  latter  discussion. 

4.0  INTERVIEW  RESULTS 

Martin  Marietta  personnel  conducted  interviews  with  key  individuals  associat¬ 
ed  with  U.S.  Air  Force  TAC  C3  training  exercises  for  the  purpose  of  estab¬ 
lishing  user  perceptions.  Questions  were  centered  around  the  BLUE  FLAG  train¬ 
ing  exercise  and  the  TALON  computer  model.  Answers  to  these  questions  were 
supportive  of  the  BLUE  FLAG  type  training  exercises,  although  responses  in¬ 
dicated  some  skepticism  with  regard  to  the  TALON  model. 

The  major  complaint  concerning  the  BLUE  FLAG  type  exercise  was  the  lack  of 
communications  during  the  planning  and/or  logistical  (implementation  of  plan¬ 
ned  operations)  phases  of  an  exercise  of  such  magnitude.  When  asked  about 
implementing  automated  logistics,  most  of  the  individuals  interviewed  were 
not  acquainted  with  sophisticated  automation  techniques,  and  could  not  con¬ 
tribute.  The  majority  of  the  individuals  interviewed  expressed  interest  in 
the  results  of  any  study  which  might  determine  the  impact  of  automated  plan¬ 
ning  and  logistics  for  exercises  of  the  scope  of  BLUE  FLAG.  Automated  plan¬ 
ning  and  logistics  could  provide  for  an  inherent  communications  capability 
for  all  phases  of  a  BLUE  FLAG  type  of  exercise. 

All  of  the  individuals  interviewed  expressed  interest  in  the  ASGI  concept 
and  were  hopeful  that  the  system  could  be  built  and  implemented.  Most  of 
these  interviewees  did  not  have  a  background  in  software  design  techniques 
to  enable  them  to  engage  in  detailed  discussion  on  the  impacts  of  a  highly 
interactive  system  such  as  is  proposed  in  the  ASGI. 

5.0  TALON  ANALYSIS 

Analysis  of  the  TALON  program  was  accomplished  by  examining  the  support  docu¬ 
mentation  for  TALON  and  through  interviewing  key  personnel  associated  with 
the  use  of  the  TALON  program.  The  discussion  of  the  current  TALON  program 
focused  on  its  capabilities  and  limitations. 

6 • 0  OVERVIEW  OF  THE  TALON  MODEL 

TALON  was  introduced  into  the  Air  Force  by  the  Tactical  Systems  Division  and 
has  been  accepted  by  the  tactical  training  centers  at  both  TRADOC  of  the  U.S. 
Army  and  the  Tactical  Air  Command  of  the  U.S.  Air  Force.  TALON  is  a  valid 
representation  of  combined  air  and  ground  warfare  for  use  in  joint  Air  Force/ 
Army  studies. 

The  ground  war  model  is  a  modified  version  of  the  Tactical  Warfare  Simulation 
Program  (TWSP)  developed  at  McDonnell-DouglaB  and  the  Center  for  Naval  Analy¬ 
sis.  The  tactical  air  operations  and  graphic  output  were  produced  by  the 
U.S.  Air  Force,  General  Purpose  and  Airlift  Forces,  Studies  and  Analysis. 
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The  interactive  features  were  produced  at  the  Tactical  Forces  Weapons  Center, 
Studies  and  Analysis  (TFWC/SA) . 


TALON  is  currently  being  used  by  both  the  Air  Force  and  the  Army  at  AF/SAGR// 
AF/SAGC,  Washington,  D.C.  ;  TFWC/SA,  Nellis  Air  Force  Base,  Nevada,  and  CADA, 
Ft.  Leavenworth;  and  TRASANA,  White  Sands,  New  Mexico.  The  technical  contact 
for  TALON  is  Major  Robert  Boyde  at  Nellis  AFB,  telephone:  702-643-2676. 

The  TALON  program  models  three  (3)  independent,  but  interactive,  combat  oper¬ 
ations.  These  are  (1)  ground  combat  model;  (2)  air/ground  model  not  includ¬ 
ing  air  to  air  combat;  (3)  reconnaissance  model  which  includes  data  collec¬ 
tion,  fusion,  and  display.  The  TALON  model  is  an  extension  of  the  hand-play¬ 
ed  war  game  philosophy.  Tactical  decisions  are  left  to  the  players;  bookkeep¬ 
ing  and  computational  chores  are  given  to  the  computer.  However,  tactical 
planning  for  a  TALON  game  only  attempts  to  parallel  actual  operational  plann¬ 
ing. 

The  TALON  model  organizational  structure  is  composed  of  a  main  routine  and 
eleven  subroutines.  The  organizational  structure  is  illustrated  in  Figure  1. 
Six  subroutines  are  currently  operational  with  the  remaining  five  subroutines 
to  be  developed.  As  indicated  in  Figure  1  TALON  receives  input  data  from  an 
outside  source  to  stimulate  a  ground  combat  situation.  Specific  data  con¬ 
cerning  terrain,  weapon  types  for  allied  and  enemy  troops,  troop  mass,  re¬ 
connaissance,  capabilities  and  limitations,  and  the  type  of  scenario  to  be 
simulated  are  part  of  the  input  stream.  The  input  stream  itself  la  a  data 
file  on  magnetic  tape  or  can  be  a  resident  file  built  by  the  TALON  staff 
either  interactively  or  through  batch  processing,  Currently,  ground  combat 
simulation  is  baselined  on  a  U.S.  Army  generated  ground  combat  scenario 
called  SCORES,  which  is  discussed  bel.ow.  The  baseline  itself  is  a  result  of 
micro-Bimulations  of  battalion  level  combat  operations  carried  out  by  the 
Army  at  Ft.  Leavenworth.  The  output  from  these  simulations  is  a  "killer  - 
victim  scoreboard"  which  is  used  to  derive  sets  of  simultaneous  equations 
relating  unit  strengths  to  combat  losses.  TALON  uses  t1  e  input  data  supplied 
by  the  SCORES  scenario  to  generate  interactive  input/output  with  the  game 
players  to  enable  the  players  to  decide  what  type  of  operation  is  desired. 
TALON  takes  the  player's  response  and  calls  one  or  more  of  the  eleven  sub¬ 
routines  to  perform  the  gaming  task. 

As  indicated  in  Figure  1,  each  routine  is  designed  to  perform  a  specific 
function.  These  routines  are  written  in  FORTRAN  IV  and  utilize  an  overlay 
structure  to  minimize  core  requirements.  Total  resource  in  core  is  a  result 
of  the  sum  of  the  lengths  of  the  longest  overlay  path  used  by  the  system. 

Core  required  for  TALON  is  approximately  200K  words.  Communication  between 
modules  is  accomplished  by  common  areas  of  data  and  data  file  activities. 

o  MAIN  -  This  routine  serves  as  the  interactice  link  between 

the  players  and  the  computer  manages  the  calling  of 
all  of  the  subroutines. 

o  GLADIATOR  -  This  subroutine  performs  air  logistics  and  cloBe  air 

support  simulation  for  ground  combat  modeling. 
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o  RECKONER  -  This  subroutine  performs  reconnaissance  modeling 

and  data  fusion  correlation. 

o  SABER  -  This  subroutine  is  the  ground  combat  simulator. 

o  ATTACKER  -  This  subroutine  performs  ground  attack  planning  and 

weapon  support  for  the  ground  combat  simulator. 

o  ALLOCATOR  -  All  air  strike  operations  to  be  used  in  support  of 

ground  combat  simulation  are  defined  by  this  sub¬ 
routine, 

o  DISPLAYER  -  This  subroutine  performs  the  processing  necessary  to 

display  graphically  the  combat  game  being  played. 

o  SUPPRESSOR  -  This  subroutine  performs  defense  suppression  modeling 

and  analysis  for  attacking  combat  masses. 

o  ATTRITOR  -  Similar  to  the  defense  suppression  subroutine,  this 

subroutine  performs  air  defense  modeling  and  analysis 
for  attacking  combat  masses. 

o  MANAGER  -  This  subroutine  models  sensor  or  advanced  warning 

detection  simulation. 

o  DEFENDER  -  This  subroutine  performs  defense  suppression  defini¬ 

tion  for  the  defense  suppression  simulator, 

o  MESSENGER  -  All  command,  control  and  communication  synthesis  is 

simulated  by  this  subroutine. 

In  addition  to  providing  graphics  display  of  the  combat  game  and  player 
interactive  capability,  TALON  provides  a  hard  copy  printed  output  of  the 
simulation  results  to  be  used  during  off-line  simulation  analysis. 

When  completed,  the  TALON  model  Is  supposed  to  be  capable  of  interactively 
simulating  every  aspect  of  an  air/ground  battle  engagement. 

6 . 1  TALON  PLAYER/ COMPUTER  INTERACTION 

As  illustrated  in  Figure  2,  TALON  play  interaction  is  done,  in  three  (3) 
major  areas;  air  support,  ground  operations,  and  reconnaissance  operations. 
The  TALON  program  prompts  and  responds  to  the  player  to  enable  the  player 
to  set  up  initial  conditions  for  the  program  to  operate.  The  interaction 
itself  utilizes  Tectronix  4014  or  40.81  graphic  terminals  for  graphic  dis¬ 
plays.  The  player  enters  commands  by  selection  of  menu  items  or  entering 
commands  through  the  keyboard  on  the  graphic  terminals. 

The  TALON  program  incorporates  combined  comr and  elements  (Division,  Regiment 
and  Battalion)  essentially  on  one  command  level!  divisional  command  staff 
which  usually  is  comprised  of  Flag  Staff  or  Field  Grade  personnel. 

Since  the  operation  of  TALON  is  an  event-sequenced  process,  specific  displays 
can  be  requested  by  the  players  at  player  prescribed  time  intervals  to  aid 
in  decision  making.  These  output  displays  show  the  player  graphic  represent¬ 
ations  of  the  perceived  ground  war,  as  obtained  from  reconnaissance  flights, 
a  summary  of  ground  operation  .,  and  results  of  air  strikes.  The  player  can 
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FIGURE  ?  TA1.0N  PLAYER/COMPUTER  INTERACTION 
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then  display  the  true  ground  war  situation  in  order  to  compare,  that  with  the 
perceived  situation.  Also,  the  player  can  choose  the  option  of  automatic 
airstrike  allocation  should  the  situation  warrant.  Variations  from  the  pre¬ 
planned  response  threads  are  permitted  whenever  the  events  indicate  a  change 
in  tactics.  The  displays  are  generated  and  sent  to  the  graphics  terminals 
by  the  DISPLAYER  module.  These  displayes  are  "snap  shots"  of  the  war  situa¬ 
tion  at  pre-selected  intervals.  The  intervals  determine  the  "real  time" 
nature  of  the  display  capability,  since  intervening  situational  data  is  not 
available  for  display.  "Time"  is  by  definition  a  simulation  variable. 

6 . 2  GRAPHIC  DISPLAYS:  TALON  CONCEPT 

A  typical  TALON  display  is  the  visual  representation  of  troop  movement  or 
troop  moments  as  illustrated  in  Figure  3.  As  shown  in  Figure  3,  troop  move¬ 
ments  are  indicated  by  a  number  and  a  vector  of  some  length.  The  number 
represents  the  size  of  the  troop  unit  in  tank-units.  The  vectors  indicate 
the  direction  of  movement  and  the  vector  length  represents  distance  traveled 
from  a  known  position.  Most  of  the  TALON  displays  are  static. 

6 . 3  GAME  OPERATIONS  AREA;  TALON 

The  TALON  gaming  program  incorporates  ground  and  ground  air  support  opera¬ 
tions  only.  While  the  TALON  program  is  useful  as  a  tactical  training  tool, 
its  ground, 'ground  air  support  limitations  inhibit  real-world  combat  simula¬ 
tions  due  to  the  fact  that  TALON  players  are  not  given  the  ability  to  simu¬ 
late  any  other  combined  military  operations. 

The  TALON  program  does  not  include  the  command,  control  and  communication 
capabilities  to  support  a  combined  tactical,  tactical  nuclear  and  strategic 
operations  environment.  It’s  development  was  intended  and  therfore  limited 
to  ground  and  tactical  air  (Air  Force)  operations.  Accomodating  the  exten¬ 
sion  to  include  combined  operations  definitely  requires  a  redesign  of  the 
MESSENGER  module,  most  likely  other  modules  would  require  some  revision  if 
not  complete  functional  duplication  including  a  parallel  capability  for  the 
03  environment  of  a  combined  force.  A  complete  assessment  of  the  impacts 
of  such  development  for  TALON  was  not  made.  Recent  improvements  to  TALON 
allow  for  combined  NATO  operations  for  the  tactica]  environment. 

6 . 4  GAME  COMMAND  LEVELS:  TALON 

The  TALON  program  incorporates  combined  command  elements  on  one  basic  com¬ 
mand  level:  divisional  command  staff.  These  elements  are  division,  regiment 
and  battalion  level  only. 

6.5  GROUND  COMBAT  OPERATION:  TALON 

The  TALON  ground  war  simulator  handles  the  movement  and  attrition  of  combat 
and  supporting  units,  The  ground  units  are  divided  into  two  sets:  RED  units 
for  offensive  or  aggressing  play  and  BLUE  units  for  defensive  play.  The 
differences  between  an  offensive  unit  and  a  defensive  unit  lie  principally  in 
how  their  movements  are  controlled.  The  routines  for  both  unit  types  are 
chosen  by  the  gamers  prior  to  simulation  execution  and  are  specified  by  their 
X-Y  coordinates.  However,  an  offensive  unit  is  not  constrained  from  movement 
unless  prevented  by  the  terrain,  its  opponents,  or  direct  orders  from  its 
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gamer  commander.  In  other  words,  the  offense  must  remain  in  motion.  A 
defensive  unit  is  constrained  in  place  unless  its  movement  is  triggered  by 
a  gamer  set  option.  This  option  is  set  prior  to  simulation  execution.  The 
TALON  program  is  supposed  to  incorporate  new  features  which  will  eliminate 
these  constraints  and  allow  free  movements  for  both  RED  and  BLUE  units. 

The  TALON  program  defines  combat  engagement  at  the  moment  the  control  zones 
of  the  respective  units  overlap  as  illustrated  in  Figure  4.  The  circles 
represent  the  control  zones  of  the  RED  and  BLUE  units.  When  any  portion  of 
the  RED  and  BLUE  zones  overlap,  combat  engagement  is  considered  to  be  happen¬ 
ing.  Total  engagement  is  considered  to  be  happening  when  one  of  the  circles 
is  superimposed  upon  the  other. 

Attrition  during  combat  is  computed  from  a  modified  form  of  the  Lanchester 
equations  based  on  the  following  principles: 

o  The  rate  of  attrition  suffered  by  a  unit  during  combat  is  directly 
proportional  to  the  combat  strength  of  its  components. 

o  The  total  attrition  suffered  by  a  unit  is  the  sum  of  the  attrition 
rates  achieved  by  each  of  its  opponents. 

o  A  unit  divides  its  fire  power  equally  against  all  of  its  opponents. 

o  A  supporting  unit  divides  its  fire  power  equally  against  all  close 
combat  opponents  of  the  units  it  is  assigned  to  support. 

The  attrition  achieved  by  a  unit  is  the  product  of  its  strength  and  the 
killing  rate  assigned  to  its  type. 

Attrition  ■  (Unit  Strength)  X  (Unit  Killing  Rate) 

The  unit  strength  in  the  TALON  program  is  defined  as  a  measure  of  the  unit's 
ability  to  reduce  its  opponents'  strengths  that  is,  the  strength  of  a  unit 
is  a  measure  of  its  ability  to  engage  in  combat  and  the  killing  rate  of  a 
unit  is  the  unit's  ability  to  reduce  its  opponent's  capability  for  combat. 
Thus,  the  concepts  of  "unit  strength"  and  "unit  killing  rate"  are  closely 
related  and  are  defined  in  terms  of  a  common  measure:  tank  units.  "Unit 
strengths"  are  expressed  as  "tank  equivalents"  and  "unit  killing  rates"  are 
expressed  as  "tank  equivalent  kills  per  unit  time."  Therefore,  attrition  is 
defined  as: 

Attrition  -  (Unit  Strength)  X  Tank-Equivalence /Unit  Strength 

X 

(Unit  Killing  Rate)  X  Tank-Equivalence/Unit  Killing  Rate 
2 

Attrition  »  (Tank-Equivalence)  /Time. 

TALON  defines  tank  equivalence  as  follows: 

o  Three  combat  infantrymen  -  1  Tank  unit 

o  Two  armored  personnel  carriers  -  1  Tank  unit 

o  One  heavy  artillery  piece,  self  propelled 

(155mm  or  larger)  or  one  M60  Tank  -  1  Tank  unit 
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The  Tank  unit  is  based  on  the  performance  characteristics  of  the  Soviet 
Union's  T-62  heavy  tank.  Equating  one  M60  tank  or  one  self-propelled  artil¬ 
lery  piece  of  155mm  or  larger  to  one  Soviet  T-62  tank  is  apparently  an 
acceptable  equivalence  for  this  type  of  modeling.  However,  there  is  a  prob¬ 
lem  in  equating  three  infantrymen  with  one  T-62  tank,  although  that  may  be 
true  depending  upon  the  weapons  available  to  those  particular  men.  In  any 
case,  military  problems  simulated  by  the  TALON  model  yield  only  a  rough 
approximation  to  the  solution  of  those  problems.  Although  the  tank  equiv¬ 
alencies  for  weapons  strength  assessments  makes  the  probability  of  success 
and  attrition  computations  very  simple,  a  great  deal  of  computations  are 
required  in  determining  the  various  effort  factors  and  uncertainty  parameters 
which  are  generated  during  operation  of  the  simulation.  These  calculations 
are  done  during  the  data  reduction  and  analysis  phase  of  the  war  game  opera¬ 
tion  which  requires  additional  man-hours  and  often  requires  that  the  same 
simulation,  partial  or  in  total,  be  re-run  in  order  to  clarify  portions  of 
the  simulations. 

6.6  AIR  RECONNAISSANCE  OPERATIONS;  TALON 

Air  reconnaissance  operations  in  TALON  include  both  data  gathering  and  data 
fusion  to  produce  a  "perceived"  picture  of  the  battlefield.  The  results  of 
the  reconnaissance  operations  may  be  used  by  the  gamers  in  the  air  strike 
planning,  or  directly  by  analysts  in  studies  of  the  reconnaissance  opera¬ 
tions  themselves.  Data  gathering  is  accomplished  through  reconnaissance 
flights  and  intelligence  from  combat  units.  The  fusion  itself  is  accomplish¬ 
ed  by  the  RECKONER  module  and  the  methods  used  are  discussed  below. 

All  air  reconnaissance  missions  are  entered  by  the  gamers  from  a  terminal 
and  executed  during  later  gaming.  The  terminals  used  are  CRT's,  either 
graphic  or  non-graphic  devices.  The  program  permits  two  (2)  types  of  mis¬ 
sion  planning: 

o  Single  reconnaissance  flights  entered  individually. 

o  Periodic  missions  entered  once,  with  each  flight  causing  the  next  to  be 

scheduled  after  a  specified  delay. 

Both  Army  and  Air  Force  reconnaissance  systems  are  available  to  the  gamers. 
Any  reconnaissance  system  may  be  programmed  into  the  model  depending  on  the 
desires  of  the  TALON  gaming  Study  Director. 

Both  reconnaissance  flights  produce  a  sensor  "footprint"  over  the  combat  area 
and  each  enemy  unit  lying  within  this  footprint  is  examined  to  determine  if 
it  has  been  detected.  The  process  of  detection  is  simulated  by  computing  the 
probability  of  detection,  depending  on  terrain,  weather,  aircraft  altitude, 
and  sensor  characteristics.  Random  numbers  are  used  with  these  computed 
probabilities  to  determine  if  the  target  is  detected.  The  identities,  loca¬ 
tions  and  velocities  of  the  detected  enemy  ground  unitB  are  stored  for 
transmission  to  the  data  fusion  center. 


Target  data  from  the  airborne  sensors  are  received  by  the  data  fusion  center 
(1)  if  reconnaissance  aircraft  survives  the  mission,  or  (2)  if  the  aircraft 
has  a  data-link  to  the  center.  If  an  aircraft  having  a  data-link  to  the 
fusion  center  fails  to  survive  the  mission,  all  data  collected  previous  to 
the  aircraft  destruction  or  incapacitation  will  be  received  by  the  fusion 
center, 

Additional  data  target  information  is  collected  and  sent  to  the  data  fusion 
center  by  sensors  accompanying  the  ground  units.  The  "perceived"  picture  of 
the  battlefield  is  a  composite  of  information  from  both  airborne  and  ground 
sensors.  Information  is  allowed  to  decay  over  a  period  of  time  and  the  in¬ 
formation  received  from  a  sensor  is  weighted  according  to  the  sensor's  known 
accuracy . 

The  TALON  model  for  reconnaissance  is  quite  sophisticated  and  appears  to  per¬ 
form  adequately  for  gaming  purposes. 

6.7  AIR  SUPPORT  OPERATIONS;  TALON 

Superimposed  upon  the  ground  component  of  TALON  1b  a  representation  of  tacti¬ 
cal  air  operations.  The  alr/ground  strike  operations  are  carried  out  in  two 
phases:  preparation  of  the  air  strike  assignments  and  computation  and  ground 
target  losses. 

Unlike  the  ground  unit  tactics,  which  are  determined  by  the  decisions  of  the 
game  players,  the  planning  for  air  strike  operations  may  be  done  by  either 
the  players  themselves  or  it  may  be  done  by  the  program.  In  the  automatic 
mode,  the  program  prepares  three  target  nomination  lists: 

o  All  engaged  enemy  units  whose  strengths  combined  with  their  supporting 
units  are  greater  than  the  strengths  of  the  BLUE  units  and  their  support¬ 
ing  units  (the  Close  Air  Support  candidates) . 

o  All  moving  enemy  units  (the  "momentum"  targets) . 

o  All  enemy  ground  units  (the  "mass"  targets). 

These  target  lists  are  weighed  according  to  the  square  of  the  distance  of  the 
unit  distance  from  a  designated  Fire  Support  Coordination  Line  (FSCL) ,  and 
ranked  according  to  their  weighted  value.  As  nearly  as  possible,  the  program 
assigns  the  preferred  aircraf t/weapon  mix  to  the  target  and  at  specified 
periodic  intervals,  these  allocations  are  displayed  to  the  game  players,  who 
may  accept  them  as  they  are  or  modify  them  as  they  wish. 

Air  strike  execution  in  TALON  is  done  at  a  designated  time  known  as  time-over¬ 
target  (TOT) .  As  this  TOT  the  strike  aircraft  appear  in  the  target  areas  at 
their  specified  altitudes.  When  the  close  air  support  aircraft  are  given  the 
location  of  their  targets,  the  aircraft  are  sent  to  the  location  predicted 


from  the  last  known  position  and  velocity  of  the  target  unit.  Once  in  the 
target  area,  the  pilot  searches  within  his  visual  detection  range  for  tar¬ 
gets  matching  his  munitions  load.  For  example,  if  the  aircraft  is  equipped 
with  anti-armor  weapons,  then  the  first  type  of  target  sought  is  an  armored 
unit.  The  search  is  modeled  in  two  stages: 

o  A  random  number  is  compared  with  the.  computed  coverage  probability 
to  determine  if  the  target  is  obscured  by  terrain  or  by  cloud  cover. 

o  If  the  target  is  in  the  clear,  then  a  new  random  number  is  compared 
with  the  target  detection  probability  to  determine  if  the  pilot  does 
see  the  target. 

An  attack  on  a  target  occurs  when  the  target  passes  both  tests  and  is  con¬ 
sidered  "detected."  Attrition  to  the  ground  units  by  an  air  strike  is  a 
deterministic  process.  Each  pass  of  the  attacking  aircraft  destroys  some 
quantity  of  ground  unit  strength.  This  depends  upon  the  target  type  and  the 
munitions  used  against  it.  These  damage  factors  are  based  on  weapon  effective¬ 
ness  tables  in  the  Joint  Munition  Effectiveness  Manual  (JMEM) . 

6.8  COST,  SCHEDULE,  AND  MANPOWER  REQUIREMENTS:  TALON 

Accounting  estimates  in  the  TALON  gaining  model  are  divided  into  two  (2) 
areas:  major  studies  and  minor  studies. 

A  major  study  effort  is  one  for  which  the  entire  data  base  must  be  developed. 
The  study  director  and  study  team  create  the  combat  scenario.  U.  S.  Army 
personnel  are  tasked  to  produce  the  TALON  ground  war  input  which  is  done  us¬ 
ing  the  SCORES  (Scenario  Oriented  Recurring  Evaluation  System)  gaming  model 
produced  at  the  Combined  Combat  Arms  Center,  Fort  Leavenworth,  Kansas.  The 
SCORES  input  consists  primarily  of  the  definition  of  the  ground  maneuver  and 
supporting  units  with  their  path  points. 

In  addition  to  the  development  of  a  complete  data  base,  a  major  study  effort 
often  requires  program  modifications  to  support,  the  simulation  of  a  specific 
exercise . 

A  minor  study  may  use  a  data  base  that  has  already  been  developed  in  the 
course  of  some  other  study  and  will  not  require  significant  program  changes, 
if  any . 

Projected  scheduling,  cost  and  manpower  requirements  for  the  TALON  model  In¬ 
cluding  the  generation  of  the  SCORES  ground  data  input  source  are  discussed. 

6.9  SCHEDULING 

The  SCORES  program  is  used  to  generate  data  for  the  TALON  model  gaming 
exercises  and  must  be  considered  as  part  of  the  scheduling  criteria  for 
scenario  generation.  SCORES  is  uBed  to  generate  data  for  either  major  or 
minor  studies. 


$ 


14. 


Major  studies  require  the  modification  of  some  of  the  application  software 
routines.  The  number  and  the  extent  of  modifications  to  be  done  is  determined 
by  a  study  team.  Changes  to  an  existing  data  base  for  complete  development  of 
a  new  data  base  is  also  a  necessary  factor  in  the  generation  of  the  SCORES 
ground  war  data.  All  changes  to  software  used  in  SCORES  is  accomplished 
through  the  submittal  of  punched  cards.  After  compilation  and  error  correct¬ 
ing  activities  are  complete,  the  simulation  system  must  be  built  by  perform¬ 
ing  a  system  generation  operation  (SYSGEN) .  The  SCORES  program  is  now  ready 
to  run  or  more  likely  to  begin  its  first  round  of  testing  for  eventual  run. 
Time  requirements  for  SCORES  execution  depends  upon  the  complexity  of  the 
major  study.  Analysis  is  performed  on  the  resulting  output  data  before  the 
data  is  submitted  to  the  Air  Force  for  use  in  the  TALON  model.  Scheduling 
requirements  for  the  complete  sequence  of  events  to  obtain  usable  SCORES 
data  for  a  major  study  appears  to  be: 

1)  2  to  4  months  to  obtain  study  requirements. 

2)  1  to  2.5  months  to  effect  program  modification  and  data  base 
development . 

3)  3  to  4  month  of  SCORES  execution  to  obtain  usable  data. 

4)  1  to  3  months  to  perform  data  analysis  activities  to  determine 

validity  of  generated  data. 

For  a  major  study  effort,  a  maximum  of  13  months  and  a  minimum  of  7  months 
are  required  to  generate  SCORES  input  data  for  TALON  combat  gaming. 

Minor  study  efforts  require  minimal  changes  to  the  applications  programs  and/ 
or  data  base.  Therefore,  minor  study  scheduling  requirements  are: 

1)  1  to  2  months  for  study  requirements. 

2)  1  month  or  less  for  program  modifications  and  data  base  changes. 

3)  1  to  2  months  of  SCORES  execution  time  to  obtain  usable  data. 

4)  1  to  3  months  to  conduct  data  analysis  activities  to  determine 

validity  of  generated  data. 

The  maximum  time  needed  for  a  minor  study  effort  is  8  months  with  a  minimum 
time  of  3  months. 

The  TALON  scheduling  itself  is  similar  to  that  of  the  SCORES  program.  For 
major  studies  with  the  TALON  program,  modification  to  certain  application 
routines  is  needed  along  with  necessary  changes  to  data  bases  to  be  used. 

In  many  cases,  development  of  a  new  data  base  is  required.  All  program 
editing  and  data  base  inputs  are  accomplished  by  using  punched  cards  as  in 
SCORES.  A  SYSGEN  operation  is  required  before  TALON  can  execute.  Data 
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reduction  and  analysis  can  be  done  as  the  TALON  program  executes,  however, 
most  of  the  data  analysis  activity  is  done  after  TALON  execution  completion. 
The  scheduling  requirements  for  a  major  study  effort  using  the  TALON  combat 
gaming  program  are: 

1)  2  to  3  months  to  obtain  study  requirements. 

2)  1  to  2  months  to  effect  program  and  data  base  changes. 

3)  3  to  4  months  of  TALON  execution  to  complete  the  desired  combat 

simulations . 

4)  3  to  4  months  to  perform  data  reduction  and  analysis 
activities. 

Total  scheduling  requirements  for  a  TALON  major  study  are  13  months  maximum 
and  9  months  minimum. 

Minor  study  efforts  using  TA..ON  do  not  necessarily  require  changes  in  the 
applications  programs  or  the  data  bases  to  be  used.  If  any  changes  are  done, 
they  are  generally  minor  in  nature  and  require  that  a  SYSGEN  be  accomplished. 
Scheduling  requirements  for  TALON  minor  study  are: 

1)  0  to  1  month  to  obtain  study  requirements. 

2)  0  to  1  month  to  effect  program  and  data  base  changes,  if  any. 

3)  1  to  2  months  to  perform  data  reduction  and  analysis  activities. 

Total  TALON  scheduling  requirements  for  completion  of  a  minor  study  are  6 
months  maximum  to  2  months  minimum. 

6.10  COST 

Cost  factors  associated  with  automated  war  gaming  exercises  are  inconsistent 
in  relation  to  other  military  operating  costs.  Unlike  hardware  and  other 
logistical  items,  the  software,  the  hosting  computer  and  associated  hardware 
require  different  cost  projections.  The  type  vf  hardware  chosen,  the  type 
or  types  of  software  used,  maintenance  and  updating  of  that  software  and  user 
utilization  of  the  hardware  and  software  influence  the  cost  of  supporting 
automated  war  gaming  capabilities. 

Projected  cost  of  the  TALON  exercise  Including  activities  required  to  gener¬ 
ate  the  SCORES  input  data  used  in  the  TALON  model  are  included  in  Figure  5. 
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7.0  ASGI  ANALYSIS 


Analysis  of  the  ASGI  concept  was  done  by  establishing  goals  that  the  ASGI 
would  meet  and  then,  through  proven  design  concepts,  establishing  a  con¬ 
ceptual  model  for  those  goals.  Many  of  the  criteria  used  in  these  concepts 
have  been  well  proven  in  Martin  Marietta's  own  C3  Laboratory.  The  goals  of 
an  advanced  ASGI  are : 

1.  To  provide  a  man-machine  interface  (MMI)  that  will  establish  a  "friendly" 
environment  to  both  game  players  and  game  supervisory  personnel. 

2.  To  provide  advanced  graphic  display  capabilities  including  the  facility 
to  interactively  create  new  displays  or  display  formats  and  the  ability 
to  save  those  permanently  or  temporarily  for  later  use. 

3.  To  provide  a  gaming  system  whose  characteristics  are  data  controlled, 

i.e.,  whenever  a  change  is  desired  in  the  gaming  scenario,  only  the  data 
needs  alteration  and  software  need  not  be  modified. 

4.  To  provide  the  ability  to  change  the  scenario  Interactively  even  when 
the  game  is  in  progress. 

5.  To  provide  a  software  architecture  which  would  allow  for  future  upgrad¬ 
ing  of  the  existing  system  with  minimum  impact  upon  existing  software. 

7.1  MAN-MACHINE  INTERFACE  (MMI) i  ASGI 

The  MMI  will  provide  a  "friendly"  environments  A  "friendly"  environment  is 
one  which  allows  non-computer  personnel  to  easily  understand  the  options 
available  and  to  be  able  to  select  an  option  with  no  need  for  prior  knowledge 
of  any  contrived  and/or  complex  command  language. 

The  man-machine  interface  shall  provide  menus  whenever  possible  for  option 
selection  with  either  light  pens,  when  available,  or  keyboard  input.  Addi¬ 
tionally,  the  MMI  shall  provide  displays  of  ground/air/sea  situations  using 
standard  symbols  maintained  by  the  system  in  a  symbol  library.  These  symbols 
will  include  naval  symbols  for  weapons  systems,  aerial  symbols  for  aircraft 
and  aircraft  types  and  ground  unit  symbols  normally  used  to  display  types  of 
ground  units  including  designations  for  unit  size.  The  MMI  will  also  provide 
the  ability  for  users  to  create  additional  symbols  interactively  and  assign 
them  t,o  the  symbol  library  or  to  establish  special  purpose  symbol  libraries. 
Other  features  of  the  MMI  include  the  ability  to  change  scale  easily  (zoom 
or  pan),  change  the  display  area,  and/or  displayed  overlays  by  the  use  of 
menu  selections.  An  overlay  in  the  ASGI  concept  would  each  be  independent 
of  the  other  overlays  (meaning  that  each  could  be  selected  or  deselected 
independently  for  display,  not  that  each  may  or  may  not  affect  the  other  in 
the  modeling  itself)  and  would  include: 

1.  A  terrain  model  overlay. 

2.  A  weather*  model  overlay. 

3.  A  cultural  overlay  (towns,  cities,  industrial  centers,  etc.). 


4.  A  ground  transportation  network  overlay. 

5.  Lines  of  communication  overlay  (two  for  each  team  (1)  known  LOC's  for 
friendlies,  (2)  perceived  LOC’s  for  enemy). 

6.  A  line  of  advance  (LOA)  or  retrograde  overlay  (two  for  each  team  (1) 
known  LOA's  for  friendlies,  (2)  perceived  LOA's  for  enemy). 

7.  A  weapons  situational  overlay  (two  for  each  team  (1)  known  positions  and 
strength  for  friendlies  (2)  perceived  positions  and  strength  for  enemy). 

The  MMI  would  allow  for  the  definition  and  specification  of  new  overlays 
interactively,  whose  interaction  with  the  modeling  system  would  be  determined 
by  the  user.  Further  discussion  of  overlays  will  follow. 

7.2  ADVANCED  GRAPHICS ;  ASGI 

The  concepts  of  the  advanced  graphics  in  the  ASGI  are  closely  related  to  the 
capabilities  of  the  MMI.  Although  the  MMI  allows  the  user  to  interact  with 
the  graphic  functions,  it  does  not  define  those  functions.  (We  will  discuss 
the  graphic  capabilities  proposed  for  ASGI  in  this  section.)  The  advanced 
graphics  capabilities  include: 

1.  High  resolution  vector  graphics. 

2.  Full  color. 

3.  Light  pen. 

4.  Rapid  context  switching  to  include  scale  change,  overlay  selection/ 
deselection. 

5.  Extended  line  quality  features  to  include  vector  generation  intensity 
change,  blinking,  and  dash,  dashdot,  or  similar  line  features. 

7.2.1  High  resolution  graphics  allows  complex  information  to  be  easily  dis¬ 
played  and  understood  by  the  viewer.  Specifically,  complex  maps  with 
features  that  might  include  roads,  cities,  terrain  features  via  symbols  and 
text  must  be  displayed  simultaneously  in  a  gaming  environment  such  as  ASGI. 

7.2.2  Full  color  requirements  are  derived  from  the  ASGI  concepts  that  allow 
selection/deselection  of  numerous  overlays,  many  of  which  might  be  viewed 
simultaneously.  In  this  case  if  only  black  and  white  were  used,  even  with 
intensity  selection  available,  overlays  would  tend  to  wash  together;  and  the 
situational  environment  on  complex  maps  would  become  very  confusing  to  the 
strategist.  Full  color  allows  each  overlay  to  receive  a  user  defined  color, 
thereby,  clearly  defining  and  separating  the  overlays  that  are  displayed 
simultaneously.  These  colors  may  also  be  redefined  interactively  for  partic¬ 
ular  overlays  even  while  that  overlay  is  being  displayed.  This  might  be 
done  in  order  to  accentuate  that  overlay  or  to  move  it  further  into  the 
background  of  visual,  perception. 

7.2.3  There  are  many  requirements  in  the  proposed  ASGI  concept  for  light 
pen  capabilities.  These  include  requirements  for: 

1.  Selection  of  menu  options  displayed  by  the  MMI. 
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2.  Designation  of  weapons  sytems  for  a  variety  of  reasons. 

3.  Selection  or  alteration  of  existing  routes  for  weapons  systems  inter¬ 
actively, 

4.  Acknowledgement  of  high  priority  conditions  presented  by  the  ASGI  syBtem, 
i.e.,  the  acknowledgement  of  engagement  commencing  for  strike  delayed 

or  cancelled,  etc. 

5.  Defining  user  oriented  symbols  interactively. 

6.  Defining  new  or  altering  existing  overlays  interactively. 

7.2.4  Rapid  context  switching  allows  users  to  select  new  areas  of  interest, 
new  combinations  of  overlays  and  new  viewing  scales  and  to  have  the  requested 
display  as  quickly  as  possible.  No  estimate  is  given  for  response  time  be¬ 
cause  response  time  will  vary  with  the  complexity  of  the  display  requested 
and  the  load  on  the  mainframe  at  the  time  the  request  is  made.  For  the  pur¬ 
pose  of  the  ASGI  concept  "rapid"  should  be  considered  to  mean  less  than  five 
(5)  seconds  for  complex  displays;  although,  the  computer  resource  available 
at  the  time  of  any  request  will  determine  response.  In  order  to  accommodate 
rapid  context  switching  the  ASGI  system  was  designed  to  give  priority  to 

MM1  requests  and  the  system  allocates  CPU  resources  in  order  to  provide 
maximum  real-time  Interaction  between  man  and  machine, 

7.2.5  The  extended  line  quality  features  referred  to  in  7.2,  Item  No.  5 
are  required  by  the  ASGI  system  in  order  to  enhance  the  display  abilities 

of  the  syBtem  over  and  above  the  capabilities  provided  by  full  color.  When¬ 
ever  the  requirement  exists  to  change  a  pathway  for  a  moving  weapons  system, 
the  ASGI  system  should  provide  a  low  intensity  mask  of  the  existing  route 
for  that  system.  The  existing  path  may  also  be  a  dashed  line  of  a  selected 
color  to  prevent  confusion  with  the  background  overlays  being  displayed. 
Referring  to  the  displayed  path,  the  user  may  choose  to  alter  only  the 
destination  of  one  or  more  of  the  way  points  along  the  path;  or  he  may 
choose  to  designate  a  totally  new  route  whose  graphic  features  may  again  be 
some  new  combination  of  intensity,  line  quality,  etc.,  in  order  to  dif¬ 
ferentiate  the  new  path  from  the  old  and  from  the  other  overlays  being  dis¬ 
played.  The  display,  designation,  or  alteration  of  routes  for  weapons 
systems  is  used  only  as  an  example  of  the  utility  of  the  extended  line 
quality  features, 

7.3  DATA  CONTROLLED  SYSTEM?  ASGI 

The  concepts  involved  in  the  specification  and  development  of  a  software 
system  that  is  controlled  by  incoming  data  are  well  developed.  Affecting  a 
change  in  the  operation  of  a  gaming  system  should  require  only  a  change  in 
the  "rules"  (in  this  case  data)  and  should  not  require  changes  in  the  soft¬ 
ware  system  itself.  To  accomplish  this  goal,  the  proposed  ASGI  syBtem  in¬ 
cludes  a  weapons  modeling  system  that  relies  only  on  data  to  determine 
either  success/failure  ratios  for  possible  conflicts  or  attrition  rates  for 
j  conflicts  that  occur.  The  data  used  is  provided  by  the  game  participants 

and  from  the  data  bases  generated  by  the  game  operations  personnel.  The 
}  game  participant  or  gamer  would  provide  a  local  tactical  direction  such 
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as  requiring  a  weapons  unit  in  "dig  in"  or  to  camouflage,  or  the  gamer  might 
determine  a  route,  that  allows  the  unit  to  maintain  high  ground  along  a  route 
or  in  some  way  affect  another  tactical  advantage.  These  tactical  situations 
would  not  be  limited  to  ground  warfare,  but  would  include  any  weapons  system 
whose  use  may  be  affected  by  the  tactical  environment.  Another  example  would 
be  an  interdiction  mission  to  be  flown  against  a  known  Surface  to  Air  Missile 
Sight  (SAM)  or  any  other  ground  based  threat.  In  this  case  the  gamer  might 
determine  both  the  ingress/egress  routes  and  the  tactics  to  be  employed. 

These  tactics  might  include  a  choice  of  low  level,  medium  level,  high  level 
ingress  and/or  egress  coupled  with  type  of  attack  which  might  include  choices 
such  as  laser  designation,  laser  guided  bombs,  conventional  weapons  using  a 
conventional  attack  or  conventional  bombs  with  curvilinear  attack  (where  the 
option  exists).  In  each  case  both  the  chance  of  mission  success  and  the 
probability  of  friendly  weapons  system  survival  are  greatly  affected  by  the 
choice  of  tactics  and  routes.  To  add  to  the  complexity  of  these  problems, 
there  are  other  situations,  the  number  of  which  should  be  arbitrary,  that 
either  significantly  or  marginally  affect  the  outcome  of  engagements  between 
weapons  systems.  These  include  but  are  not  limited  to  the  affects  of  fire 
support  availability,  both  organic  and  temporarily  assigned,  weather,  ter¬ 
rain  conditions,  communications  systems  (LOG' a),  lines  of  supply,  or  even 
soil  conditions  in  the  battle,  area.  There  is  a  limit  to  what  is  feasible  to 
include  in  a  data  base  for  war  game  scenarios,  but  the  point  is  that  the 
ASGI  would  provide  the  mechanism  both  to  establish  the  data  in  the  data  base 
and  to  provide  the  algorithim  that  would  account  for  the  factors  available 
in  the  data  base  to  compute  probability  of  success  and  any  required  attri¬ 
tion  rates. 

7 . 4  INTERACTIVE  SCENARIO  ALTERATION;  ASGI 

Because  the  proposed  ASGI  system  and  its  actions  are  keyed  from  data  that 
reside  in  the  overlay  data  files  and  weapons  system  files,  affecting  those, 
data  affects  the  gaming  itself.  The  ASGI  concept  provides  the  game  super¬ 
visors  with  utilities  that  use  the  MMI  to  allow  the  alteration  of  overlay 
data  on-line  or  weapons  data  for  either  or  both  players  on-line.  This 
could  be  done  while  the  game  :ls  being  played,  thereby  creating  a  dynamically 
changing  gaming  situation  for  the  game  players.  This  interaction  allows  the 
same  scenario  to  be.  flexible  enough  to  exercise  both  the  commanders  and  the 
established  lines  of  communication  for  many  tactical  situations. 

7 • 5  SOFTWARE  SYSTEM  ARCHITECTURE; _ ASGI 

The  ASGI  system  software  architecture  design  was  derived  from  the  philoso¬ 
phies  developed  in  Martin  Marietta's  own  C3  laboratory  over  the  last  three 
years.  These  philosophies  involve  a  central  process  known  as  the  Master 
Executive  whose  function  it  is  to  maintain  communications  between  and  execu¬ 
tion  of  a  number  of  dependant  tasks.  Bath  of  these  tasks  has  a  unique  func¬ 
tion  and  may  communicate  with  and/or  request  the  execution  of  any  number  of 
other  functional  tasks  through  interaction  with  the  Master  Executive.  One 
advantage  of  this  approach  is  that  new  capabilities  may  be  added  to  the 
system  by  development  of  new  tasks  for  integration  into  the  software  system. 
Because  of  th'3  modularity  of  the  system,  these  new  tasks  can  be  integrated 
with  the  minimum  impact  to  the  existing  system.  The  new  task  would  com- 
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municate  to  the  system  through  the  Master  Executive  and  would  be  able  to 
utilize  any  system  facility  that  already  existed.  Communication  itself 
occurs  utilizing  a  standard  binary  transaction  message  protocol  or  a 
standard  character  oriented  message  format.  These  messages  are  then  passed 
to  the  Master  Executive  for  handling.  The  Master  Executive  in  turn  notifies 
an  already  executing  task  of  a  message  pending  or  even  schedules  the  required 
task  for  execution  in  order  to  accommodate  the  message  transaction  request. 
Other  advantages  involve  the  integration  of  upgraded  versions  of  existing 
tasks.  Because  the  only  interaction  between  tasks  is  that  of  message  traf¬ 
fic  that  is  handled  by  the  Master  Executive,  the  performance  of  any  new  or 
upgraded  modules  or  tasks  can  be  monitored  by  examination  of  the  critical 
message  traffic.  Problems  in  any  new  or  modified  software  can  be  quickly 
identified  and  exhaustive  testing  can  be  accomplished  minimizing  the  time 
required  in  the  testing  phases. 

Another  advantage  to  the  proposed  ASG1  design  concept  is  that  the  system  is 
a  top  down  design  that  can  easily  be  moved  into  a  multi-processor  or  network 
environment  where  the  Master  Executive  would  reside  in  more  than  one  CPU. 

The  Centralized  Communications  Buffer  could  be  moved  to  shared  memory  or 
without  shared  memory,  machines  may  be  networked  by  utilizing  the  capabili¬ 
ties  of  vendor  network  operation  systems.  If  both  of  the  previous  options 
were  not  feasible,  special  purpose  communications  drivers  could  be  written 
to  update  the  centralized  communications  buffer  in  any  CPU  to  reflect  mes¬ 
sage  traffic  occurring  between  tasks  regardless  of  where  that  task  might  be 
executing. 


; . 6  TASKS  WITHIN  THE  ASGI 

Following  is  a  discussion  of  the  function  of  each  task  in  the  proposed  ASGI. 
This  includes  a  discussion  of  the  interaction  between  tasks.  For  clarity 
tasks  will  also  be  referred  to  by  their  alpha-numeric  designations  as  shown 
on  the  functional  system  diagram  in  Figure  6. 

1.  The  Master  Executive-AO  or  (BO) 
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The  Master  Executive  or  in  the  case  of  a  second  CPU,  the  Calculator 
Processor  Master  Executive,  controls  the  execution  of  all  tasks  within 
the  system.  Moreover,  the  Master  Executive  notifies  executing  tasks 
of  messages  in  queue  for  that  task  and  receives  notification  of  mes¬ 
sages  from  executing  tasks  that  need  to  be  processed.  The  Master 
Executive  schedules  tasks  for  execution  for  reasons  other  than  message 
handling.  The  Master  Executive  also  executes  the  Simulated  Clock  Manager 
(A6)  upon  interrupt  from  the  hardware  system  clock  when  resources  are 
available.  For  each  occurrance  of  the  simulated  unit  time,  the  Master 
Executive  schedules  the  Scenario  Event  Manager  (A2).  The  simulated 
unit  time  is  not  necessarily  the  same  as  the  hardware  system  clock.  If 
the  Simulated  Clock  Manager  notifies  the  Master  Executive  to  schedule 
the  next  execution  of  the  Scenario  Event  Manager  (A2)  before  the  last 
execution  is  completed,  then  simulated  time  will  be  deferred  to  allow 
completion  of  the  last  event  series. 


22. 


•r 


V 


2.  The  Event  Sequence  Manager  -  A1 

The  main  function  of  the  Event  Sequence  Manager  ia  that  of  initiation 
of  user  and/or  operation  requested  events.  These  events  may  be  the 
launch  of  a  reconnaissance  or  air  strike  sortie  or  the  destruction  of  a 
key  bridge  at  a  time  specified  by  the  operations  personnel  in  order  to 
affect  the  tactical  situation.  One  of  the  actions  that  is  scheduled 
through  the  Event  Sequence  Manager  is  that  of  recording  the  existing 
scenario  environment.  Because  of  this  function  the  Event  Sequence 
Manager  can  also  be  thought  of  as  a  situational  camera  system  whose  job 
it  is  to  save  all  pertinent  event  data  necessary  to  "replay"  the  scenario 
from  that  simulation  time.  In  the  process  of  reviewing  any  game  played, 
the  Event  Sequence  Manager  can  also  play  through  the  situations  saved  in 
any  requested  order,  designated  by  simulation  time.  This  provides  the 
system  the  maximum  flexibility  to  assist  in  the  educational  process. 
Although  the  Event  Sequence  Manager  does  maintain  event  tables,  the 
historical  data  is  managed  through  interaction  with  the  Event  Files 
Access  Manager  (A3) . 

3.  The  Scenario  Event  Manager  -  A2 

All  key  model  events  are  maintained  by  the  Scenario  Event  Manager.  The 
Job  is  not  only  that  of  determining  that  an  event  has  occurred,  such  as 
two  weapons  systems  becoming  engaged,  but  maintaining  engagement  status 
of  weapons  systems  and  requesting  the  activation  of  the  Probability  of 
Success/Attrition  Model  Manager  (B2)  and  passing  the  required  data  for 
attrition  computation  through  interaction  with  the  Master  Executive  and 
the  use  of  the  Centralized  Communications  Buffer.  For  all  weapons 
systems,  moving  or  not,  the  Scenario  Event  Manager  maintains  a  Track 
Status  File.  The  Scenario  Event  Manager  also  requests  service  from  the 
Track  Performance  Modeling  Manager  for  all  moving  weapons  units  to  com¬ 
pute  new  positional  data  for  each. 

4.  Event  File  Access  Manager  -  A3 

All  direct  data  base  access  is  performed  by  the  Event  Files  Access 
Manager.  This  process  maintains  a  scenario  data  file,  a  master  scenario 
data  file  and  a  history  file.  Any  process  within  the  ASGI  system  can 
request  data  from  the  Event  Files  Access  Manager  or  request  storage  of 
new  data  into  either  the  scenario  file  or  the  history  file.  The  master 
scenario  data  file  is  the  starting  point  for  the  scenario  Itself.  The 
scenario  file  is  used  by  the  system  as  the  dynamic  model  and  may  be  up¬ 
dated  by  any  process  within  the  system. 

5.  Card/Interactive  Input  Manager  -  A4 

All  non-graphic  terminals  and  card  inputs  are  received  for  syBtem  dis¬ 
semination  by  the  Card/Interactive  Input  Manager.  In  the  case  where 
particular  overlays  such  as  terrain,  transportation,  or  cultural  models 
require  input  for  generation  of  a  new  scenario  or  the  interactive  edit¬ 
ing  of  existing  data,  the  Card/Interactive  Input  Manager  communicates 
through  the  Master  Executive  (AO)  to  the  Event  Files  Access  Manager  in 
order  to  effect  the  scenario  master  file.  Any  weapons  data  that  is  not 
graphic  in  nature  can  be  edited  or  entered  via  interactive  terminals 
through  this  process. 
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6.  Display  File  Creation  Manager  -  A5 

The  Display  File  Creation  Manager  is  a  key  element  in  the  man-machine 
interface.  This  process  allows  the  user  to  create  new  displays  by  in¬ 
dicating  desired  display  scales,  formats,  overlays,  color  and  intensity 
schemes,  symbol  usage,  etc.  These  designated  displays  may  be  specified 
and  the  criteria  saved  either  temporarily  or  permanently  for  later  use. 
The  Display  File  Creation  Manager  interacts  extensively  with  the  Graphics 
I/O  Manager  in  order  to  complete  the  graphics  portion  of  the  man-machine 
interface. 

7.  Simulation  Clock  Manager  -  A6 

The  Simulation  Clock  Manager  is  a  task  that  determines  the  rate  at  which 
the  simulation  will  run.  Simulation  time  may  be  slowed  or  even  stopped; 
or  simulation  time  may  be  accelerated  to  speeds  limited  only  by  the  CPU 
resource  availability.  The  limit  to  how  fast  a  simulation  can  occur  is 
directly  proportional  to  the  computer  resource  available  and  inversely 
proportional  to  the  complexity  of  the  simulated  scenario.  The  simulated 
time  can  be  changed  by  gaming  operations  personnel  through  communications 
originating  from  the  Post  Test /On-Line  Support  Manager.  No  consideration 
has  been  given  to  running  the  Simulation  Clock  Manager  backwards  in  time 
since  the  facility  to  snapshot  the  dynamic  system  at  any  time  has  been 
provided. 

8.  Graphics  I/O  Manager  -  A7 

The  Graphics  I/O  Manager  maintains  communication  with  the  Display  File 
Creation  Manager  through  the  use  of  the  binary  message  protocol.  The 
speed  of  communication  between  the  Graphics  I/O  Manager  and  the  Display 
File  Creation  Manager  (A5)  is  critical  in  order  to  assure  quick  responses 
to  display  requests  from  the  viewers.  All  graphic  displays  are  routed 
through  the  Graphics  I/O  Manager.  Change  requests  such  ae  color,  inten¬ 
sity,  scale  (where  data  is  local)  and  menu  changes  are  made  internal  to 
the  Graphics  I/O  Manager,  but  any  other  requests  will  require  further 
inter-task  communications. 

9.  Radar  Simula)  ion  Manager  -  Bl 

Radar  is  one  of  the  critical  tools  in  modern  warfare,  There  are  many 
types  of  radar.  Some  are  used  for  target  acquisition,  others  for  track¬ 
ing  or  ranging.  The  Radar  Simulation  Manager  will  have  the  capability  to 
determine  when  or  if  a  target  can  be  sighted  arid  tracked  for  any  given 
radar  capability  and  target  return  characteristics.  The  model  will  by 
necessity  be  somewhat  simplistic  in  nature  in  order  to  simulate  any 
radar.  The  Radar  Simulation  Model  Manager  will  provide  each  player  with 
a  view  of  the  "as  Received"  aerial  warfare  model  to  assist  in  decision 
making.  Additional  capabilities  include,  limited  simulation  of  acquisi- 
r  tion  radars  that  may  be  airborne  in  weapons  systems  of  either  team.  In 

this  case  the  Scenario  Event  Driver  (A2)  would  request  target  acquisi- 
!  tion  probabilities  of  a  known  target  from  the  Radar  Simulation  Manager. 

|  Relative  altitudes  of  the  airborne  systems  would  be  provided  along  with 

'  weapon  types  and  radar  types.  After  computation  of  the  acquisition 
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probabilities,  the  Radar  Simulation  Model  would  return  results  to  the 
Scenario  Event  Manager  (A2). 

10.  Probability  of  Success/Attrition  Model  Manager  -  B2 

The  Probability  of  Success/Attrition  Model  Manager  calculates  either 
probability  of  success  for  engagements  in  the  perceived  or  In  the  real 
warfare  models.  In  the  case  of  a  request  for  a  calculation  of  the  prob¬ 
ability  of  success  from  a  gaming  participant,  it  is  the  gamer's  respon¬ 
sibility  to  obtain  intelligence  about  the  position,  strength  and  type  of 
opponent  forces.  Because  calculations  are  done  using  his  perceived  model, 
the  commander  will  receive  proper  results  from  those  calculations  only  if 
hi1'  perceived  model  is  equivalent  to  the  real  model  in  the  area  local  to 
the  calculations.  Attrition  rates  are  always  based  on  the  real  models 
of  the  scenario.  The  methodology  used  in  these  calculations  of  attri¬ 
tion  will  be  discussed  later  in  this  report. 

11.  Message  Queue  Manager  -  B3 

The  Message  Queue  Manager  queues  messages  and  time  tagged  eventB  as¬ 
sociated  with  message  traffic  occurring  on  the  centralized  communications 
buffer.  This  process  works  closely  with  the  Master  Executive  to  manage 
the  centralized  communications  buffer,  which  is,  in  fact,  a  dynamic 
region  whose  size  is  determined  by  the  Message  Queue  Manager.  Using  the 
traffic  activity  rate  to  calculate  resource  required,  the  Message  Queue 
Manager  either  allocates  or  deallocates  space  as  needed  to  maintain  the 
efficiency  of  the  centralized  message  buffer. 

12.  Track  Performance  Modeling  Manager  -  B4 

Any  moving  system  has  mobile  characteristics  that  might  include  the 
ability  to  maneuver,  travel  within  particular  speed  ranges  or  travel 
over  or  through  rough  terrain.  The  Track  Performance  Modeling  Manager  is 
activated  by  request  from  the  Scenario  Event  Manager  (A2)  to  provide  the 
updated  position  of  every  weapons  unit  given  its  present  speed  and  direc¬ 
tion,  desired  speed  and  direction  and  the  weapons  system  type.  New 
positions,  new  headings  and  speeds  are  calculated  using  data  determined 
by  the  weapons  characteristic  file  that  is  accessed  by  the  Track  Perfor¬ 
mance  Modeling  Manager.  The  new  data  is  returned  to  the  Scenario  Event 
Manager  (A2)  after  computation. 

13.  Positional  Transformation  Manager  -  B5 

The  Positional  Transformation  Manager  is  used  to  establish  new  coordi¬ 
nate  transformations  at  simulator  time  for  each  dynamic  overlay  within 
the  gaming  model.  Moving  models  are  those  that  have  characteristics 
similar  to  the  weather  model  overlay.  These  overlays  act  like  moving 
units  that  may  translate  and  rotate  across  the  terrain  overlay  model. 
Moving  overlay  models  that  would  depend  on  the  weather  model  (winds) 
include  overlays  for  determination  of  affected  areas  in  nuclear,  nerve 
gas  or  biological  warfare  confrontations.  The  Positional  Transformation 
Model  Manager  provides  the  ability  to  move  these  overlays  over  the  ter¬ 
rain  model  to  simulate  moving  weather  or  to  establish  threat  from 
nuclear  or  other  weather  dependent  weapons  systems. 
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1A.  Intelligence/Reconnaissance  Model  Manager  -  B6 

The  Event  Files  Access  Manager  maintains  a  file  named  the  Scenario  File. 
This  file  contains  a  complex  set  of  data  including,  among  other  things, 
a  perceived  situational  model  for  the  Blue  team  of  Red  team  positions 
and  weapons  strengths,  a  perceived  situational  model  for  the  Red  team  of 
the  Blue  team  positions  and  weapons  strengths  and  an  actual  model  of  Red 
and  Blue  positions  and  weapons  strengths.  It  is  the  responsibility  of 
the  commanders  of  each  team  to  assure  proper  reconnaissance  so  that  the 
perceived  models  are  updated  to  the  greatest  extent  possible  in  order 
to  assure  reliable  information  upon  which  to  base  command  decisions. 
Whenever  an  intelligence  gathering  vehicle  is  active,  the  Scenario  Event 
Manager  requests  activation  of  the  Intelligence/Reconnaissance  Model 
Manager  to  determine  if  that  vehicle  has  detected  an  enemy  position. 

This  process  first  determines  if  the  intelligence  vehicle  has  the  capa¬ 
bility  to  detect  the  specific  weapons  system,  given  the  sensors  available 
to  that  vehicle.  Then,  if  detection  can  occur,  a  calculation  is  made  to 
determine  if  detection  did  occur.  If  detection  was  made,  then  the  pro¬ 
cess  continues  by  determining  what  intelligence  was  gathered  given  the 
sensors  used.  The  Intelligence/Reconnaissance  Modeling  Manager  notifies 
the  Scenario  Event  Manager  of  any  intelligence  gathered  for  the  sighting. 
Thus,  the  perceived  adversary  models  for  each  team  are  updated. 

15.  Interactive  Scenario/Overlay  Modification  Manager  -  B7 

While  the  game  is  in  progress,  the  game  operations  personnel  can  activate 
the  Interactive  Scenario/Overlay  Modification  Manager.  This  process 
provides  the  ability  to  update  or  change  any  data  used  by  the  ASGI  in 
determining  model  activities.  This  includes  all  overlays,  weapons  sys¬ 
tems  characteristics  and  moving  model  speeds  or  rates  of  rotation.  This 
process  is  operated  either  through  the  Graphics  I/O  Manager  (A7)  or 
through  the  Card/lnteractlve  Input  Manager  (AA) ,  Where  map  data  must 
be  affected,  the  updates  must  take  place  through  the  Graphics  I/O  Manager 
(A7) .  All  other  types  of  updates  can  be  affected  through  either  a 
graphics  station  or  a  character  oriented  interactive  station. 

16.  Post  Test/On-Line  Support  Manager  -  B8 

The  Post  Test/On-Line  Support  Manager  provides  the  tools  for  system 
resource  monitoring  by  the  operations  technicians.  From  this  process 
the  status  of  CPU  resource  and  status  of  mass  storage  devices  is 
monitored.  System  changes  can  be  made  if  necessary  during  game  play  to 
prevent  overflow  of  open-ended  files  such  as  the  Event  Files  Access 
Manager's  history  file.  After  the  game  has  been  terminated,  the  Post 
Test/On-Line  Support  Manager  can  produce  user  related  reports  of  the 
battle  situations  at  the  intervals  saved  on  the  history  file  and  can 
produce  parallel  system  reports  for  operations  purposes.  These  reports 
are  statistical  in  nature  and  indicate  player  performance  and  effective¬ 
ness  according  to  methods  not  yet  determined. 


t 

f 

I 

26. 


i 

i 


ASGI  Application  Software  Arcbitectu 


Figure  6 


7 . 7  ASGI  PLAYER/COMPUTER  INTERACTION 


Figure  7  illustrates  a  typical  ASGI  concept  of  player /computer  interaction. 
The  symbols  for  ground  units  are  typical  of  those  generally  in  use  and  the 
colors  used  will  be  blue  or  red  to  indicate  team.  Their  positions  are  up¬ 
dated  to  reflect  true  positions  at  simulator  time.  In  the  case  of  either 
blue  or  red  team  displays,  however,  the  scene  will  reflect  only  the  perceived 
environment  according  to  what  intelligence  each  has  gathered.  Additional 
features  such  as  cultural  overlays  or  transportation  overlays  are  incorporat¬ 
ed  on  demand  (see  Figures  7a,  7b) .  These  features  will  be  available  from 
menu  selections  via  the  lightpen  or  keyboard  input  at  the  user's  option. 

Any  overlay  within  the  system  will  be  available  for  immediate  callup.  As 
previously  mentioned,  any  of  these  overlays  can  be  individually  addressed 
and  their  colors  and/or  intensity  changed  and  those  criteria  saved  for  later 
use  in  the  same  display  or  for  displays  of  other  areas. 

As  play  progresses  in  the  ASGI  concept,  commanders  can  specify  lineB  of  ad¬ 
vance  for  his  units  and  interactively  request  from  the  computer  probability 
of  success  computed  for  contemplated  engagements.  The  commander  may  also 
issue  orders  to  units  to  maintain  high  ground  or  dig  in  or  indicate  some 
other  tactical  option  for  that  unit.  When  the  option  doss  not  already  exist 
in  the  data  base,  the  ASGI  system  will  query  the  operations  personnel  to 
either  provide  the  necessary  data  for  computing  probability  of  success  and 
attrition  rates  against  units  most  likely  to  be  engaged;  or  if  the  decision 
is  made  not  to  allow  the  request  of  the  commander,  a  message,  selected  or 
written  by  the  operations  personnel  will  Indicate  non-compliance. 

The  intelligence  model  and  the  air  warfare  model  (air  to  air  and  air  to 
ground)  are  separate  overlays  that  interact  with  the  ground  model.  The  air 
to  air  model  will  in  turn  interact  with  the  air  to  ground  model.  A  commander 
may  request  intelligence  sorties  displayed  on  the  ground  model  map.  The 
overlay  would  indicate  routes  of  flight  and  times  for  the  route  way  points 
(see  Figure  8).  The  commander  can  alter  these  at  will.  The  ASGI  assumes 
communication  availability  according  to  the  communications  model  within  the 
data  base.  If  the  communications  model  allows  the  indicated  Borties  to  be 
affected,  ther.  the  new  routes  and/or  times  will  be  complied  with.  If  not, 
the  flight  would  be  flown  aB  previously  scheduled. 

Although  most  flights  are  scheduled,  some  user  specified  resources  sit  alert 
with  ordinance  loaded  as  per  commander's  request.  The  scenario  may  include 
an  air  environment  preplanned,  but  any  resource  may  be  rescheduled  or  planned 
weapons  loadings  may  be  altered  by  the  commanders.  Naturally,  commanders 
may  alter  planned  routes  or  weapons  loads  only  for  sorties  directly  under 
their  control.  In  order  to  affect  other  changes,  he  must  exercise  the  com¬ 
munications  of  the  game  to  request  changes  of  the  proper  commanders. 

The  ASGI  concept  of  player/computer  interaction  is  that  of  a  completely 
dynamic  system  with  any  overlay  easily  selectable  for  immediate  viewing.  The 
scene  represents  the  present  simulator  time  perceived  picture  with  easily 
understood  symbols  whose  positions  represent  the  positions  of  the  units  in 
question.  The  user  may  request  further  information  about  any  unit  by  in¬ 
dicating  a  unit  with  a  light  pen  and  pointing  to  a  menu  option  that  requests 
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unit  strength.  In  the  menu  box  will  appear  the  unit  strength,  weapons  avail¬ 
able,  percent  attrition  inflicted,  and  weapons  units  in  support. 

7.8  ASGI  GAME  OPERATIONS  AREAS 

The  proposed  ASGI  system  would  Bupport  five  operations  areas  for  gaming 
scenarios.  These  are: 

1.  Ground 

2.  Air 

3.  Naval 

A.  Strategic 
5.  Combined 

The  incorporation  of  these  areas  is  a  matter  of  including  the  desired  over¬ 
lays  to  the  ground  model  for  gaming.  Where  TALON  allows  ground  and 
ground/air  support  operations  only,  ASGI  would  offer  a  greatly  enhanced 
capability  to  simulate  war  scenarios.  The  communications  environment  can 
be  specified  to  realistically  portray  any  combined  operations  desired. 

7.9  ASGI  GAME  COMMAND  LEVELS 

The  ASGI  would  employ  five  (5)  levels  of  command: 

1.  Divisional 

2.  Regimental 

3.  Battalion 
A .  Company 
5.  Combined 

Gaming  scenario  generation  to  the  company  level  gives  an  ASGI  system  the 
versatility  to  simulate  a  wide  range  of  military  exercises. 

7 . 10  GROUND  COMBAT  OPERATIONS:  ASGI 

The  ASGI  ground  combat  operations  workB  with  each  individual  weapons  system 
moving  within  their  respective  overlays.  Eminent  conflict  is  defined  when 
the  areas  controlled  by  adversary  units  begin  to  come  into  contact.  When 
contact  occurs,  the  Probability  of  SuccesB/Attritlon  Model  Manager  Task 
queries  the  weapons  data  base  for  the  variables  used  to  compute  attrition. 

To  understand  this  calculation,  the  data  contained  within  the  data  baBe  must 
be  examined. 

The  data  in  the  weapons  data  base  is  similar  to  a  multi-layered  two  dimen¬ 
sional  table  with  every  weapons  system  contained  in  both  row  and  column  (see 
Figure  9).  If  an  aircraft  is  engaging  a  ground  target,  for  example,  then 
the  appropriate  factor  is  retrieved  for  that  engagement  in  the  given  environ¬ 
ment.  That  figure  is  used  in  the  attrition  calculation.  Weapons  systems 
themselves  are  not  equivalenced  to  some  common  weapons  unit  strength  as  in 
TALON.  This  lends  realism  to  the  gaming  environment  where  a  tank  may  be 
easy  prey  to  an  A-10  aircraft,  but  the  A- 10  aircraft  might  not  be  able  to 
cope  with  a  quad-2 3mm  gun  that  is  camouflaged.  The  quad-23mm  gun,  however, 
may  be  no  match  for  a  large  tank,  thus  completing  the  triangle. 
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The  algorithm  for  computing  attrition  and  probability  of  success  has  not 
been  developed.  The  equations  would  be  alterable  by  operations  personnel 
without  software  changes.  One  of  the  inputs  proposed  for  the  Post  Test/On¬ 
line  Support  Manager  is  the  attrition  and  probability  of  success  equations 
to  be  used  by  the  Probability  of  Success/Attrition  Model  Manager  Task.  This 
feature  will  allow  interactive  empirical  testing  of  new  equations. 

7.11  AIR  RECONNAISSANCE  OPERATIONS;  ASGI 

All  air  reconnaissance  missions  must  be  scheduled.  The  schedules  generally 
would  be  provided  in  the  preplanned  scenario  including  routes  and  flight 
times.  These  would  be  set  up  much  as  any  reconnaissance  profile  with  com¬ 
manders  altering  flight  times  and/or  routes  of  flight  to  best  gather  the 
necessary  intelligence. 

Intelligence  gathered  would  be  determined  by  the  Intelligence/Reconnaissance 
Model  Manager  Task.  Factors  involved  in  this  determination  would  include 
data  concerning: 

o  Weather  conditions 
o  Terrain  in  the  surveillance  window 
o  Type  of  aircraft  used 
o  Surveillance  altitude 
o  Sensor  types  carried 
o  Aircraft  radar  signature 
o  Intercept  avoidability 
o  ECM  capability 

These  factors  would  not  only  determine  what  intelligence  was  gathered,  but 
also  be  used  to  determine  if  the  aircraft  involved  would  survive,  considering 
route  of  flight  and  threats.  The.  intelligence  gathered,  assuming  that  the 
information  is  recovered,  is  used  to  update  the  perceived  situation  for  the 
team  commanders. 

7.12  AIR  SUPPORT  OPERATIONS:  ASGI 

All  ASGI' s  air  operations  are  assigned  as  sorties.  The  scheduling  of  sortie 
resources  is  totally  in  the  hands  of  the  gaming  commanders.  Types  of  sorties 
are: 

o  Air  to  Air  (CAP) 
o  Close  Air  Support  (CAS) 

o  Forward  Air  Observation  for  naval  fire  support  (FAO) 
o  Forward  Air  Controller  for  Close  Air  Support  (FAC) 
o  Air  Lift  Assault,  Helicopter  (ALAH) 
o  Air  Lift  Supply/Re~supply  (ALS) 
o  Air  Lift  Medivac  (ALM) . 

For  each  of  the  above  the  scenario  would  specify  the  following: 
o  The  number  of  aircraft  available 

o  Location  of  airfields  and  the  type(s)  of  support  offered  by  each 
o  Maximum  effective  operating  ranges  for  types  of  aircraft  from 
specified  airfields. 
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Figure  10  illustrates  a  typical  menu  for  ASGI  air  operations  selection. 

After  a  selection  is  made,  the  item  is  entered  into  the  schedule  for  the 
Scenario  Event  Manager  in  order  to  activate  the  planned  route  of  flight  at 
the  appropriate,  simulation  time, 

Clcse  Air  Support  occurs  within  specified  areas  of  the  environment.  In 
order  to  have  close  air  support  operations,  either  an  airborne  FAC  or  a 
ground  FAC  must  be  available  to  control  the  air  strike.  This  is  a  case 
where  the  Rules  of  Engagement  (ROE)  must  be  considered.  Other  operations 
affected  by  ROE  are  any  Air  to  Air  confrontations  and  any  airlift  operations. 
The  rules  of  engagement  determine  capabilities  of  weapons  systems  and  sup¬ 
port  systems  to  operate.  These  rules  may  be  entirely  different  for  each 
team. 

Any  of  these  air  operations  are  affected  by: 

o  Weather  conditions  and  terrain 
o  Actual  target  air  defense  capabilities 
o  Suspected  vs  actual  enemy  positions 
o  Air  intercept  capabilities  of  enemy  fighters. 

The  air  missions  can  result  in  failure  from  any  adverse  condition,  including 
in-flight  mechanical  problems,  resulting  in  mission  aborts.  In  the  case  of 
multiple  ship  flights,  escorts  are  provided  for  aborting  aircraft  according 
to  the  rules  set  up  in  the  ROE. 

Attrition  for  engagements  are  calculated  by  the  Probability  of  Success/ 
Attrition  Model  Manager  Task  using  the  data  in  the  weapons  data  base.  In 
the  air  to  ground  engagements,  the  tactics  employed  by  the  air  and  ground 
units  are  considered  in  these  calculations.  Where  a  one  pass  attack  is 
specified  for  aircraft  against  a  ground  target,  the  chance  for  aircraft 
survival  is  maximized.  The  ground  target  itself  would  sustain  minimal 
damage  also.  Conversely,  in  an  attack  with  multiple  passes,  both  the  at¬ 
trition  rate  for  aircraft  and  the  weapons  systems  under  attack  are  greatly 
affected,  assuming  the  ground  system  offers  some  threat  to  the  aircraft. 

The  munitions  carried  by  the  aircraft  will  also  determine  how  effective 
each  pass  is  in  destroying  enemy  capabilities.  Again,  the  attrition  formulae 
are  not  developed,  but  will  be  interactively  specified  to  the  Attrition  Model 
Manager  by  use  of  the  Post  Test/On-line  Support  Manager. 

The  TALON  system,  in  comparison,  is  "hard  coded",  meaning  that  any  change 
in  the  attrition  or  probability  of  success  formulae  must  be  re-programmed 
by  software  systems  or  applications  personnel.  In  addition,  all  weapons 
systems  are  equivaleflced  to  some  common  weapons  unit,  limiting  the  ability 
to  define  complex  weapons  capabilities.  Although  the  TALON  model  accounts 
for  the  tactical  situation,  the  flexability  of  tactical  situation  specifica¬ 
tion  in  the  ASGI  system  along  with  the  complete  freedom  of  defining  weapons 
system  capabilities  against  any  other  weapons  system  provides  the  ability 
to  realistically  portray  the  interactions  of  complex  war  scenario  situations. 

7.13  NAVAL  OPERATIONS:  ASGI 

Naval  operations  in  the  proposed  ASGI  system  are  an  extension  of  the  type  of 
weapons  modeling  already  discussed  for  ground  and  air  operations.  The  dif- 
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ference  between  ground  based  and  naval  based  air  operations  is  that  the 
naval  based  air  operations  moves  with  the  aircraft  carrier.  The  other 
naval  weapons  capabilities  include  missile  and  gun  weapons  systems.  As  in 
the  ground  weapons  systems,  all  naval  weapons  capabilities  are  defined  in 
the  weapons  data  base  such  that  any  new  resource  can  be  defined  in  terms  of 
the  other  weapons  systems  and  by  the  tactical  situations  in  which  they  can 
be  employed.  For  an  individual  ship  in  a  task  force,  capabilities  would 
include  radar  acquision  and  tracking,  gun  and  missile  ranges,  speed  range 
for  the  ship  itself  and  its  manuevering  characteristics.  Any  naval  based 
weapons  system  could  operate  in  support  of  ground  based  units  limited  by 
the  ranges  of  the  various  weapons  available  for  naval  use.  This  capability 
of  combined  operations  is  constrained  by  the  lines  of  communication  (LOC's) 
and  the  rules  of  engagement  model  in  addition  to  the  physical  geographic 
model  depicting  sea/land  topography. 

A  typical  naval  combat  gaming  situation  is  illustrated  in  Figure  11.  In 
this  case  the  weapons  unit  is  made  up  of  a  task  force,  each  with  air,  mis¬ 
sile  and  gun  capabilities.  As  in  the  ground  environment,  symbols  from  the 
standard  symbol  library  or  symbols  generated  Interactively  by  operations 
personnel  or  users  represent  weapons  platforms  in  appropriate  colors.  The 
display  Itself  is  dynamic  and  represents  actual  or  in  the  case  of 
Intelligence  dependent  displays  for  the  team  commanders  the  perceived 
locations  at  simulator  time.  Like  the  ground  environment,  commanders 
schedule  sir  sorties  for  intelligence,  defense  and  attack,  along  with 
determining  movements  of  the  ships  that  make  up  the  task  force.  Factors 
for  calculating  probability  of  success  and/or  attrition  are  identical  in 
nature  to  any  other  weapons  systems. 

7.14  STRATEGIC  OPERATIONS;  ASGI 

The  area  of  strategic  operations  differs  from  any  other  discussed  thuB  far 
in  three  (3)  areas: 

1)  The  rules  of  engagement  are  separate  from  those  mentioned  earlier 
and  are  stringent  in  nature,  limiting  commander's  options. 

2)  The  weapons  systems  themselves  have  little  or  no  flexibility 
once  launch  has  occurred  and  these  launches  are  generally  not 
scheduled,  but  are  options  available  for  reaction  to  the  perceived 
strategic  situation. 

3)  The  lines  of  communications  are  generally  not  the  same  as  those 
used  for  conventional  welfare. 

These  three  conditions  require  that  the  rules  of  engagement  be  defined 
for  the  strategic  environment,  that  the  lines  of  communication,  when 
different  from  the  conventional  LOC's,  be  defined  for  the  environment.  The 
fact  that  the  weapons  systems  cannot  be  retargeted  after  launch  only 
restricts  the  commander's  options  and  requires  only  an  entry  to  indicate 
this  limitation  at  weapons  definition  time. 
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FIGURE  II  ASGI  CONCEPT;  NAVAL  COMBAT  GAMING  TASK  FORCE  CONTROL  ZONES 


7.15  COST,  SCHEDULE  AND  MANPOWER  REQUIREMENTS:  ASGI 


In  order  to  estimate  the  cost  of  this  software  system,  a  preliminary  design 
was  derived  from  the  goals  presented  earlier.  The  software  Martin  Marietta 
has  developed  over  the  last  three  years  in  its  own  Command,  Control  and  Com¬ 
munications  laboratory  was  used  as  a  basis  for  software  estimates  to  minimize 
estimating  risks.  The  software  developed  to  date  is  estimated  to  provide  29% 
of  the  total  software  needed  for  the  ASGI  system.  To  some  degree,  this  code 
must  be  modified  to  accommodate  all  the  capabilities  necessary  to  accomplish 
the  ASGI  derived  requirements. 

7.15.1  COST;  ASGI 

The  cost  of  software  development  for  the  proposed  ASGI  system  was  estimated 
using  development  models  which  include  three  phases.  Each  of  the  phases  in 
turn  are  separated  as  shown  in  Figure  12a.  Martin  Marietta  has  established  a 
software  development  model  to  help  estimate  the  cost  of  software  for  each 
phase  in  the  development  cycle.  Some  of  the  factors  accounted  for  in  the 
model  include  complexity  factors,  high  level  code  vs  assembler  code,  and 
system  software  vs  applications  software.  The  cost  of  the  software  1b  cross 
checked  by  developing  a  bottoms  up  engineers  cost  estimate  and  balancing  that 
agaLnst  a  top  down  designed  software  model  that  is  used  to  estimate  lines  of 
code.  The  result  of  this  estimating  procedure  is  shown  in  Figure  12b.  These 
costs  are  broken  down  by  task,  each  of  which  1b  divided  into  new  lines  of 
code  and  modified  lines  used  from  Martin  Marietta's  C3  software.  Totals  for 
the  entire  system  are  presented  in  Figure  12d.  This  cost  represents  only 
software  development.  If  the  project  was  supported  by  Martin  Marietta  for 
computer  time,  assuming  33%  of  development  time  spent  at  a  terminal  On-line 
and  one  hour  of  hook-up  time  costing  $10.00  per  hour,  the  computer  bill  would 
be  approximately  $360,000,00.  This  computer  estimate  uses  current  rates 
charged  for  the  VAX  11/760  at  the  Central  Software  Engineering  Facility  at 
the  Waterton  Facility  of  Martin  Marietta,  Denver  Aerospace. 


7.15.2  SCHEDULE  AND  MANPOWER;  ASGI. 

The  optimum  manning  of  the  software  effort  for  the  as  proposed  ASGI  system 
would  require  27  months  of  effort.  This  includes  all  phases  of  the  software 
development  cycle.  Manning  itself  is  presented  in  Figure  12e,  Scheduling 
the  project  for  more  or  less  than  the  specified  27  months  would  result  in  a 
more  expensive  development  effort. 


7.16  IMPORTANT  FEATURES:  ASGI 


5 


The  proposed  ASGI  concept  is  a  modular  software  system  that  maximizes  on-line 
man-machine  interaction  t,o  both  game  players  and  to  operations  personnel. 

The  function  of  building  scenario's  can  be  done  interactively  by  operations 
personnel,  though  some  functions,  such  as  terrain  model  and  weather  model 
specification  and  weapons  system  definition,  cannot  be  appreciably  affected 
by  an  advanced  interactive  input  process.  These  data  are  complex  and  will 
consequently  be  labor  intensive  for  input  in  any  environment.  At  some  point, 
technology  may  automate  the  process  of  digitizing  complex  terrain  and  weather 
data  into  a  data  base,  at  which  time  that  facility  could  be  added  to  the 
ASGI. 
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New 

Code 

Mod 

Code 

Source 

LOC 

Total 

Hrs. 

M/M 

AO  Master  Executive  (HOL) 

(Mos.  for  S/W  Oev.  6.5  Mos.) 

500 

800 

1300 

2475 

15 

A1  Event  Sequencing  Manager  (HOL) 
(Mos.  for  S/W  Dev.  7.0  Mos.) 

650 

1000 

1650 

2875 

17 

A2  Scenario  Event  Manager  (HOL) 
(Mos.  for  S/W  Dev.  7.0  Mos.) 

1030 

450 

1480 

2823 

17 

A3  Event  File  Access  Manager  (HOL) 
(Mos.  for  S/W  Dev.  4.0  Mos.) 

200 

800 

1000 

1050 

6 

A4  CARD  Interactive  Input 

Manager  (HOL) 

(Mos.  for  S/W  Dev.  13.0  Mos.) 

7850 

4900 

12,750 

18,026 

109 

A5  Display  File  Creation  Mgr. (HOL) 
(Mos.  for  S/W  Dev.  8.0  Mos.) 

1000 

3250 

4250 

5250 

32 

A6  Simulation  Clock  Manager  (HOL) 
(Mos.  for  S/W  Dev.  1.0  Mo.) 

0 

200 

200 

175 

1 

A7  Graphic  I/O  Manager  (HOL) 

(Mos.  for  S/W  Dev.  6.0  Mos.) 

200 

1550 

1750 

2194 

13 

(Mos.  for  S/W  Dev.  16.0  Mos.) 

34868 

11 ,430 

(47%) 

1 

12,950 

(53%) 

.43  Hrs. 

24,380 

per  LOC 

34,868 

35 

210 

2T5S0 

$1,220,380 


FIGURE  12b 
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New 

Code 

Mod 

Code 

Source 

LOC 

Total 

Hrs. 

M/M 

B1  Radar  Simulation  Manager  (HOL) 
(Mos.  for  S/W  Dev.  15.0  Mos.) 

14,400 

0 

14,400 

36,000 

217 

B2  Probability  of  Success/ 

Attrition  Model  Management(HOL) 
(Mos.  for  S/W  Dev.  5.0  Mos.) 

600 

0 

600 

1,050 

6 

B3  Message  Queue  Manager  (HOL) 

(Mos.  for  S/W  Dev.  11.0  Mos.) 

5,500 

600 

6,100 

10,150 

61 

B4  Track  Performance  Modeling 
Manager  (HOL) 

(Mos.  for  S/W  Dev.  6.0  Mos.) 

800 

800 

1 ,600 

2,100 

13 

B5  Positional  Transformation 

Manager  (HOL) 

(Mos.  for  S/W  Dev.  7.5  Mos.) 

1,500 

0 

1,500 

2,625 

16 

B6  Intel  1 iaence/Recon  Model 

Manager  (HOL) 

(Mos.  for  S/W  Dev.  9.5  Mos.) 

3,600 

0 

3,600 

7,200 

43 

B7  Interactive  Scenario/Overlay 
Modification  Manager  (HOL) 

(Mos.  for  S/W  Dev.  7.5  Mos.) 

1 ,600 

0 

l.uOO 

3,200 

19 

B8  Post  Test/Online  Support  Mgr. 

(HOL) 

(Mos.  for  S/W  Dev.  9.5  Mos.) 

2,000 

3675 

5,675 

7,675 

46 

Offline  Support  S/W  (HOL) 

Non  Vendor  Supplier 
(Mos.  for  S/W  Dev.  8.0  Mos.) 

2,300 

0 

2,300 

4,025 

24 

(Mos.  for  S/W  Dev.  24.0  Mos.) 

32,300 

(86%) 

5,075 

(14%) 

i 

37,375 

74,025 

445 

.  $2,590,875 

1 .98  hrs.  per  LOC 


74025 

373TF 


FIGURE  12c 
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Source  LOC 


Total 


Hours 


New  Code  Mod  Code 


M/M 


A 

11,430 

12,950 

24,380 

34,868 

210 

B 

32,300 

5,075 

37,375 

74,026 

446 

43,730 

18,025 

61 ,755 

108,893 

656 

(Mos.  for  S/W  Dev.  27.0  Mos.) 


108,893 

TT,y$5 


108,893 
_ 35 

3,811,255 


-  1 .76  hr/L.OC 

0981  t)  656  W 

Total  Software  Development  Estimate 


1  manmonth  =  166  hrs. 
1  manyear  =  2000  hrs. 


FIGURE  1 2d 


One  Important  feature  of  the  ASGI  is  that  the  sysLem  is  data  driven.  This 
means  that  the  software  system  itself,  possibly  an  unclassified  system,  might 
model  using  highly  classified  data  and  weapons  systems  specifications.  The 
A. SC! [  would  remain  unclassified  and  would  only  operate  with  the  classified 
data. 

Once  weapons,  terrain,  weather,  and  other  labor  intensive  data  is  specified 
for  an  area,  the  specification  of  the  remainder  of  the  scenario  can  be  very 
expeditious  to  implement.  Using  the  graphics  capabilities  of  the  MMI ,  opera¬ 
tions  personnel  can  easily  specify  position  and  routes  of  advance  or  retro¬ 
grade  for  weapons  units.  This  capability  does  not  affect  the  time  necessary 
to  obtain  requirements.  Should  scenarios  use  the  same  areas,  terrain, 
weather  and  weapons  models,  scenario  generation  can  be  very  quickly  done. 

Because  the  ASCII  is  functionally  modular,  any  new  system,  such  as  the  "Rosie" 
modeling  system  could  be  Incorporated  into  the  ASGI  and  use  the  facilities.' 
provided  by  the  ASGI .  The  system  is  designed  for  expeditious  upgrade  caya- 
bi.li.ties,  allowing  for  future  growth. 

The  software  architecture  provides  for  an  eventual  or  immediate  application 
to  a  distributed  computing  system,  thereby  increasing  response  to  user  inputs 
and  allowing  scenarios  of  extreme  complexity  to  be  accommodated. 

The  goals  Identified  for  the  ASGI  are  ambitious.  The  design  concepts  for  the 
ASGT  are  proven  and  realistic.  The  sizing,  cost  and  scheduling  of  the  soft¬ 
ware  development  effort  are  preliminary  in  nature,  but  provide  a  realistic 
picture  of  the  investment  required  to  implement  such  a  system.  Should  renui.ro 
meats  fur  a  new  gaming  system  bu  determined  that  are  not  as  extensive  as  those 
presented  here,  the  design  criteria  of  functional  modularity,  centralized 
o.ommun  leaf  Ions  buffer  and  standardized  message  formatting  should  be  used  to 
Insure  the  capability  of  implementing  new  features. 

; . 1 7  HARDWARE  RECOMMENDATIONS?  ASGI 

Because  the  proposed  ASGI.  requires  advanced  graphic  capabilities,  and  intel¬ 
ligent  graphic  stations  minimize  the  computer  impact  to  a  critical  CPU  re¬ 
source,  the  Evans  and  Sutherland  full  color  graphic  display  terminals  with 
picture  processor  and  picture  system  software  are  recommended.  In  order  to 
satisfy  the  requirement  that  Blue  and  Red  teams  interact  using  graphics  along 
with  operations  personnel,  three,  graphics  stations  are  necessary.  The  total 
hardware  recommended  to  develop  ASGI  is  as  follows: 

o  l-l'DP-n/70  computing  system  including  two  (2)  RP06  disk  driveB,  eleven 
(.11)  terminals,  one  (1)  high  speed  line  printer,  one  (1)  tape  drive, 
operating  system  and  system  software  and  hardware  maintenances. 
Approximate  cost  -  $'218,000.00. 

'1- Evans  ami  Sutherland  full  color  graphics  display  terminals,  picture 
system  processor,  picture  system  software  and  maintenance  for  software 
ami  hardware.  Approximate  cost  -  $400,000,00. 
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(see  Para.P7a5.1)mand°justifies°:leCtiW<’Uitl  C°St  ln  exceas  of  $300,000.00 

software  efforts.  In  addition  °n  dedicateci  hardware  for  the 

a  system  to  be  delivered  ^^0^!^  Evans  and  friend  to 

tion  time.  Total  o  f  UrdUrlT*  ¥  in3taJled  ^nimlzes  installa- 
vai  cost  ot  hardware  is  approximately  $618,000.00. 


The  choice  of  the  PDP-11/70  was  recommended  in  order 

DP-an/70lm™  SXrtent  ,the,software  ^rtin  Marietta  has 
PDP  11/70  computers  in  its  own  C3  laboratory.  This 

moved  to  a  VAX  11/780  which  allows  utilization  of  C3 

hardware  should  be  considered.  Experience  has  shown 

computer  should  be  considered  a  minimum  resource  for 

In  any4case*  every  effort  to  make  the  ASGI 
should  be  made  in  order  to  be  able  to  take  advantage 
ments  by  rehosting  the  ASGI  with  the  minimal  effort 


to  be  able  to  utilize 
developed  to  date  on 
software  is  now  being 
software  if  more  modern 
that  the  PDP-ll/70 
this  kind  of  development 
software  transportable 
of  any  hardware  improv- 
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